[nexus] Remove duplicated networking types from omicron-common / external API#10344
Conversation
|
Starting to look at this today, thank you for your patience! |
|
|
||
| // TODO-cleanup We could push `LinkFec` and `LinkSpeed` down into | ||
| // sled-agent-types-versions and re-export them instead of having these | ||
| // conversions. That requires <https://github.com/oxidecomputer/drift/pull/20>. |
There was a problem hiding this comment.
Looks like this has been merged?
There was a problem hiding this comment.
So it has! I'll file an issue (this can be done separately and shouldn't affect the external API) and replace the PR link with an issue link. Thanks.
There was a problem hiding this comment.
Note that drift 0.1.4 finds an API divergence within omicron that we'll need to fix before updating to it. My plan was to fix it yesterday but then other things happened :)
I believe you understand them correctly... but it's somewhat of an theoretical exercise because I think we don't actually use those tables today. |
Prior to this PR, we had both `PortFec`+`LinkFec` and `PortSpeed`+`LinkSpeed` (both pairs of enums that were identical except for their names and doc comments). Per @rcgoodfellow in chat, `Link*` is a more accurate name, so this PR keeps that one and removes the `Port*` enums. `LinkFec`/`LinkSpeed` were already used in the Nexus external API, so that one doesn't change at all. A bunch of internal APIs were using the `Port*` version, so those had a lot of wire-compatible churn to include the new docstrings. The diff stat here ignoring OpenAPI spec churn is `+142, -219` (net negative from removing the duplicate types and associated `From` impls). This was originally part of #10344, but was deferred to wait for some `drift` fixes, all of which have now landed, courtesy of @ahl and @sunshowers. Closes #10403.
This fixes #10293. 2/3 of these were straightforward; removing the duplicate
SwitchPortGeometry2andTxEqConfig2types required removing those fromcommonand moving any other types still incommonthat used them out intonexus-types-versions; those are done in the first two commits on this PR.Removing the duplicate
SwitchInterfaceKind2was more involved because the two types didn't have the same structure despite having the same name. This is split into two commits: 71f7db2 renames one of them toSwitchInterfaceKindNoVlanDetailsand moves it tonexus-types-versions(where it lives alongsideSwitchInterfaceKind). Then9db5a0cad8694f40e1c572f172794b2144ce4bdbmakes an API change toSwitchInterfaceConfig(changing thekindto theSwitchInterfaceKindthat includes the vlan ID) andSwitchPortSettings.The
SwitchPortSettingschange needs the most scrutiny. My understanding is that on main,SwitchPortSettingshas these two fields:where each item in
interfaceshas akindof eitherPrimary,Loopback, orVlan. If the kind isVlan, then there will be an item invlan_interfacescontaining just the interface ID and the vlan ID:This is based on both the comments and the path that inserts these into the db, where we only add items to
vlan_interfacesif it's coming from aninterfacewith theVlankind:omicron/nexus/db-queries/src/db/datastore/switch_port.rs
Lines 1398 to 1412 in 3e4c5bc
I assume the expectation here is that clients would have to reassemble these two vecs to glue together the vlan ID of any interface with a vlan by taking the interface ID from
interfacesand finding it invlan_interfaces. The change I made on this PR is to drop thevlan_interfacesfield entirely, change thekindofSwitchInterfaceConfigto include the vlan ID, then do the reassembly ourselves when we load this object from the db:omicron/nexus/db-queries/src/db/datastore/switch_port.rs
Lines 198 to 252 in 4f0da85
But please confirm that (a) I understood what these fields contained and (b) the reassembly I'm doing there is correct!